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Abstract- The purpose o-f the this report is to assist the Navy Management 
Systems Support Ot-Fice in performing software maintenance by showing a 
detailed example of applying the software change management methodology which 
was described in the previous report: 'Software Maintenance: The Need for 
Standardi zati on ' , Norman F. Schnei dewi nd , February 1989, Naval Postgraduate 
School Technical Report NPS-54-09-02. The maintenance of local area network 
software is used as the example. 

I. INTRODUCTION 

Software maintenance is a major activity at the Navy Management Systems 
Support Office (NAVMASSO) . The purpose of the this report i s to assist the 
Navy Management Systems Support Office in performing software maintenance by 
showing a detailed example of applying the software change management 
methodology which was described in the previous report: 'Software Maintenance: 
The Need for Standardi zat i on ' , Norman F. Schnei dewi nd , February 1989, Naval 
Postgraduate School Technical Report NPS-54-89-02 . The maintenance of local 
Area network software is used as the example- The methodology is general and 
can be applied to any programming environment and language, including COBOL. 

As an introduction to the subject of software maintenance, v-^e provide some 
definitions followed by an explanation of the importance of the subject- 



A- Definitions 



Software Mai n tenance: Modification of a software product after delivery 

to correct faults, to improve performance or 
other attributes, or to adapt the product to a 
changed environment fl>. 

This definition is the conventional one and is useful if our interest in 
modification to soft’ware is limited to changes that are made after the 
software is delivered- However, it is a fact that changes are not confined to 
the post-del 1 very phase; they are made during all life cycle phases. In some 
cases, changes are made in significant numbers prior to deiivery- 

Mai nt ai nab i 1 1 t y : The ease with which a software can be maintained Cl>- 

Change Management: The process of making changes to software and 

controlling their effects during the entire life of 
the software- 

The last definition recognizes the fact that modifications to software must 
be managed effectively during the entire life of the software. It is the 
definition used here. 
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According to various sources, sottnare maintenance accounts tor a 
significant amount of the total time and cost of running a data processing 
organization. For example, one study reports the following: about half of 
applications staff time spent on maintenance, over 40 percent of the effort in 
supporting an operational application system spent on user enhancements and 
extensions, and about half a man— year of effort allocated annually to maintain 
the average system x2> • In another report the same authors list the factors 
which cause the significant maintenance effort: system age, system size, 
relative amount of routine debugging, and the relative development experience 
of the maintainers f 3> . System age drives the other factors: with increased 
system age, system size increases, leading to greater effort allocated to 
routine debugging, and with increased system age, the relative development 
experience of the maintainers declines due to organi z at i onal turnover and 
change- All of these factors tend to increase the time and cost of performing 
maintenance. Thus maintenance is an area that deserves a lot of attention. 
Improvements in maintenance practices should result in reduced costs and 
increased effectiveness of performing maintenance. 

However there is a limit to reducing cost and increasing effectiveness 
through improved practices, because the maintainability of the software has 
largely been determined by the developer before it ever reaches the 
maintainer- The maintainer can only influence quality during the maintenance 
phase of the software life cycle. The quality of the software as designed is 
determined, in part, by whether the software development methodology assists 
the developer in producing maintainable software. Consequently, maintenance 
practices, which maintainers control, and development methodology, which 
developers control , are candidates for standard! z at i on f4>. Significant 
efforts have been made at the National Institute for Standards and Technology 
(formerly the National Bureau of Standards) to promote standardized 
maintenance practices through the publication of a series of guides on 
software maintenance and software maintenance management f 51 - 

The ob j ec t i ve of st andar d i z at i on is to i mpr eve the mai ntain ability of both 
existing and new software. However, we should recognize the limitations of 
using standard i zat i on to 'solve' the 'maintenance problem'- These are the 
following: 1) Much of the software that is maintained was developed without 
benefit of any methodology; consequently, methodology is of limited use in 
these cases. 2) Conversely, methodology is most useful when applied to new 
software. 3) Related to points 1 and 2 is the fact that improvements in 
maintenance practices are only applicable to existing software. 4) An 
important determinant of the maintainability of software is the knowledge and 
skill of the developer and maintainer- 5) There are other aspects of a 
development methodology, such as expressiveness, that are important when 
evaluating it as a development tool in addition to its usefulness as an aid 
for producing maintainable software. Points 4 and 5 are beyond the scope of 
the paper as are the areas of software engineering environments and tools, 
which can contribute significantly to the quality of both development and 
mai ntenance. 
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The paper consists ai the -following sections: 

II. Purpose 

III. Local Area Network Example 

IV. Objective o-f Maintenance 

V. Metrics -for Maintenance 

VI. Model o-f Maintenance 

VII. Application o-f Metrics 

VIII. Standardi zati on o-f Change Documentation 

IX. So-ftware Communication Mechanisms and Maintenance 



X. Standardi zat i on through Examination o-f Development Methodologies 

XI. Summary 



Each principle o-f the change management methodology is illustrated by the 
appropriate part o-f a local area network (LAN) so-ftware maintenance example so 
that the reader can immediately see an application. The same example is used 
throughout the paper to maintain continuity -for the reader. This example is 
used to illustrate how mistakes can be made i -f maintenance is per-formed 
without using a formal change procedure. The example is also used to show how 
mistakes can be avoided by applying the change management methodology- 
Followir.g the statement of each change methodology principle is an example 
d*^awn from the LAN application. The examples are delineated by the use of 
vertical bars < 1 ) . 



I I . PURPOSE 

The first purpose of the paper is to present the case for standar di z i ng 
software maintenance practices and those aspects of software development 
methodology that affect the maintainability of the delivered software. The 
second purpose is to show how to apply the change management methodology. 
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III. LOCAL AREA NETWORK EXAMPLE 

Since Jhre eKample will be used throughout the paper , it is necessary to 
present an overview of the LAN software maintenance application at this point. 
A discussion of all aspects of the changes which were made to the LAN software 
in the example is beyond the scope of this report. 

Figure 1 shows Servers and User Computers on a Token-Ring LAN with the 
pertinent batch programs keyed to the diagram. Briefly, the functions of these 
programs are the following: 

Server 



Autoexec . Bat : 



Start the Server on network and share resources. 



Prof i 1 e . Bat : 



Process User 
conf i gurat i on 
etc . ) . 



Computer i den t i f i cat i ons to identify 
(e.g. , modem, EGA card, 3270 Emulation, 



Set conf i gur at 1 on in memory (the en vi r onment ) . 

Application: Check configuration. Execute application program if 

Batch Files required hardware available. Otherwise, display error 
message. 



User Computer 



Autoexec . Bat : Set User Computer identification in the environment. 

User. Bat : Display logon instructions to the user. 

: Start User Computer on network. 

Server and call Profile.Bat. 



Start . Bat 



request resources from 
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Autoex ec .Bat 
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User . Bat 
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Prof i 1 e . Bat 


Start . Bat 






Physical 


Vi rtual 





NB: TOKEN-RING BOARD 



RI: RING IN 



RO: RING OUT 



Figure 1. Token-Ring Network Diagram 
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A batch (command file) for starting a user personal computer on a local 
area network (LAN) and requesting resources provided by a server is shown in 
Figure 2 (Start, Bat) and the correspondi ng state diagram is shown in Figure 3. 
This batch file was modified to provide some additional network capabilities 
as shown in Figure 2; the corr esponding modification is shown in Figure 3 with 
dotted boxes. The boxes represent states and the arrows represent state 
transi t i ons. 

The enhancement provides the ability to store the User Computer 
configuration (e.g., presence of a modem) in memory and to check the 
conf i gurat i on prior to executing an application which requires a given device. 
The purpose is to prevent the user from wasting time if the required device is 
not available, and to notify the user of this situation with a message that 
identifies computers that have the required device. In addition, a significant 
reduction in software maintenance is achieved by having only one set of 
application batch files to maintain rather than various sets, with each set 
tailored to a different conf i gurat i on . Lastly, this approach achieves a 
uniform user application program interface. 

The numbers on the left side of the commands in the batch file correspond 
to the numbers on the state boxes on Figure 3. The convention for labeling 
state transition arrows is: Event /Act i on . In some cases in Figure 3 there is 
no event; in these cases ' NE ' is used to indicate this. The DOS and PC LAN 
Program handle transfers of control implicitly (e.g., a transfer of control 
occurs automatically from PC LAN Program to DOS under certain error 
conditions). There is no capability in the batch file language for describing 
error conditions explicitly, although they are shown in the state diagram to 
clarify the Operation- 

Asterisks in the batch file identify comments. Unf ortunatel y , the comment 
concerning accessing the D drive was not changed with the modi f i cat i on . This 
comment is no longer applicable and caused confusion in trying to understand 
the program logic. With the modi f i cat i on , neither the D drive nor the 
directory program IDIR are accessed at this point in the program. The comment 
should have been changed to refer to the E drive and the PROFILE program- This 
affects the transitions from states 5 to 6 and 6 to 7. For the sake of 
brevity, the error events and actions associated with states 6' and 7' are not 
shown in Figure 3; they are similar to those for states 6 and 7. 

Neither a state diagram nor another type of methodology that would show the 
consequences of making a change was used in creating the batch program. The 
use of such a methodology would have helped to avoid this kind of error by: 

o Preventing side effects (erroneous comment) 

o Providing ability to make selective change (replace commands 6 and 7 with 
6' and 1 ' correctly). 

o Identifying existing communi cat i on linkages (communi cat i on between 
commands 6 and 7 and the D drive and its directories) and by identifying 
changed com.mun i cat i on linkages ( commun i cat i on between commands 6' and 7' and 
the E drive and its di rec tor i es ) - 
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: 5tart-Bat For Token-Ring User Computer 

1 ECHO OFF 

: Establish Path to Network and DOS Programs Residing on User Computer 

2 PATH C: \NETWQRK;C: \APrb\DOS 

; Establish Access ^or IDIR Directory Program and its IDIRDATA 

: Sub Directory 

APPEND C:\1DI RDAT A 
ECHO ON 

: Load Token-Ring Programs 

3 TOKREUI 
NETBEUI 

: Start the User Computer on the Network, Using Name Provided by 

: User (Replaceable Parameter V.l) and Specify Use of Resources 

: <e-g-, ASG = 10 Devices and Directories) 

4 NET START MSG V-l /SRV: 1 /ASG: 10 /PB1:16K /USN:3 /CMD: 12 /SES: 18 

: Request Use of Server Directories on Server TN3 and Printer on TN4: 

: Application Directory APRS (Virtual Drive E) , Application Batch Files 

: DISKD (Virtual Drive D) and Printer PRINT 

5 NET USE E: \\TN3\APPS 

NET USE D: \\TN3\DISKD 

NET USE LPTl \\TN4\PRINT 

: Access D Directory which Contains IDIR and Application Program 

: Batch F i 1 es 

6 D; 

*** Load IDIR 

7 IDIR 



Incorrect 

Modi f 1 cat 1 on : Replace commands 6 and 7 above with commands to and 7 : 

(comment was not changed) 

. D Drive which Contains IDIR and Program Batch Files 

6' E: 

: Load Profile 

7' PROFILE 



Correct 

Modification: Replace commands 6 and 7 above with commands 6' and 7": 

(change comment) 

; *** Access E Drive, which contains PROFILE program- PROFILE is located 
: on the Server. PROFILE processes User Computer i dent i f i cat i on in 

: order to identify the User Computer hardware conf i gurat i on . The 

: execution of Profile will ultimately lead to the loading of IDIR 

: and access to application batch files- 

6' E: 

: *** Load Profile 

7' PROFILE 



Figure 2- Batch file for Token-Ring LAN User Computer Start Program 
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O V I LOAD START FILE 



IDLE I ! CAN'T LOAD START 

I ! FILE/ERROR MSG. 

! I 

! NE/LQAD START FILE FROM DOS ! 

1 V V 

I CAN'T LOCATE ! ! 

START ! DIRECTORIES/ERROR MSG. I BACK AT ! 

FILE I >! DOS ! 



LOADED 



NE/EXECUTE PATH & 

APPEND COMMANDS 

CAN'T LOAD TOKEN-RING 
PROGRAMS/ERROR MSG. 



2 



DIRECTOR- 

IES 

LOCATED 



; NE/LQAD TOKEN-RING 
! PROGRAMS 

3 V 



TOKEN- 

RING 

PROGRAMS 

LOADED 



CAN'T START NETWORK/ERROR MSG- I 



1 NE/START NETWORK 



RESOURCES NOT 
AVAILABLE/ERROR MSG- 



NETWORK 

STARTED 



NE/REQUEST RESOURCES 



CAN'T 

ERROR 



LOAD 
MSG . 



IDIR/ 




5 V 


NE/ACCESS 


6 V 1 


NE/LOAD 


7 

1 

1 


RESOURCES 


DRIVE D 


DRIVE D 


IDIR 


1 DIRECTORY 
- — >! PROGRAM 


ASSIGNED 




ACCESSED 




I (IDIR) 

! LOADED 

1 

1 



DRIVE NOT DEFINED/ERROR MSG. 




NE/ACCESS 
DRIVE E 



DRIVE E . 
ACCESSED. 



NE/LOAD 

PROFILE 



PROFILE 

PROGRAM 

LOADED 



Figure 3 



State Diagram of a Token-Ring LAN User Computer Start Program 
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IV- OBJECTIVE OF MAINTENANCE 

The objective of maintenance is to make required changes in software in 
such a way that its value to users is increased- Required changes can result 
from either the need to correct errors or to increase the functionality of the 
sof tware. 

A- Maintenance Process 

In the broad view of maintenance, it is not limited to making post-delivery 
changes- Rather , it is a process that starts with user requirements and never 
ends Even the installation of and changes to a replacement system can be 

considered part of the maintenance process. Our approach to identifying the 
maintenance functions which should be standardized is to: 1) Adopt the view 

that maintenance is a process of change management and 2) Identify tasks in 
maintenance that are concerned with making ctianges to software, including 
changes to documentat i on (e-g., specification, design, listing, test plan, 
etc. ) . 

B- Maintenance Tasks 

Using the concept of change management , the following maintenance tasks can 
be identified: 

0 Identify need for change 

1 The change is desired to prevent users from accessing resources that are 
not available to them. This will save user time and reduce frustration- I 

0 Determine whether change should be made, based on benefit-cost 
anal ysi s 

1 The cost IS approx i matel y one man-day maximum to code, document and test the 

change. This amounts to about 300 (with employee benefits). This is 

equivalent to about 100 users saving 5 minutes each, assuming salary of user 
(with employee benefits) is approx i matel y equal to implementer salary, on the 
average- The break even point could be achieved within two weeks of 
implementation, given the number of users and uses of the affected application 
programs. ! 

Evaluate the effects of change, including possible side effects 

0 Determine whether change can be made without creating an 
incompatibility with the rest of the software 

1 The change will not affect user logon instructions. Thus, User. Bat, which 

contains logon instructions, will not be affected. A change will be required 
in the user Autoexec. Bat to set the environment (i.e., establish the user 
computer conf i gurat i on ) - This change will have no effect on the user 
operation- Changes will be required in the application batch files (e.g., 
Smar tcom- Bat ) that are stored on the server to add checks of the conf i gur at i on 
to see whether the user has the resources necessary to carry out the attempted 
operation- If this is not done correctly, there will be errors in the 
operation (e.g., the user will be allowed to attempt an operation that is not 
possible or will told that the operation is not possible when, in fact, it is 
possi b 1 e) - ' 
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0 Make the change, it warranted, and only it it can be done in a 
standard way 

1 The change is warranted based on the very tavorable cost— benetit 
relationship. The change can be made in a standard way by using the change 
management methodology that tollows. *• 

V. METRICS FOR MAINTENANCE 



In order to manage sottware change it is desirable to measure the ettects 
ot change. This is accomplished with quality metrics. A quality metric is 
detined as tollows: a quantitative measure ot the degree to which sottware 
possesses a given attribute that attests its quality v 1 }• . Ideally, there would 
be agreement on a set ot appl i cat i on-i ndependent , language-independent, 
sottware str ucture-i ndependent metrics ('universal metrics'). Agreement does 
not exist in the sottware engineering community on a universal set. Lacking 
this agreement, metrics which are known to be related to the et t ec t i veness and 
etticiency ot the sottware development process are used during development to 
measure and improve the development process; these are called orocess metrics 

. It is assumed that their use will result in maintainable sottware. 
However, process metrics, like tr aceabi 1 i ty , have little to do with measuring 
whether the system achieves its quality requi remen ts - For that we need product 
metrics like reliability, accuracy, response time, throughput , etc. The two 
types ot metrics are related in the sense that high process metric values 'will 
contribute to high product metric values- Product metrics are beyond the scope 
ot this report. 

The role ot metrics in maintenance can be demonstr ated by posing the 
tallowing question: 



When a maintenance action is taken, how are the relevant metrics values 
at t ected? 



o What are the relevant metrics? 



! Tr aceabi 1 i ty ! 

o What were the original values? 

! 100 X between code and state diagram I 

o What are the new values? 

I < 100 7- - Can't trace trom Start. Bat ot User Computer to Server 

application batch tiles 1 
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o Examine incremental changes 

! Are they in the right direction (e.g., reduced complexity)'^ 






I No. Increased complexity. I 

* Are they approx i matel y the right values (e.g., within the bounds ot 
experience with respect to the maintenance action)? 



! Traceability will be lost i -f the change is extensive. 
The change should not involve more than about 30 "/. of the 
batch file. If this is not the case, the batch file should 
be rewritten (rule of thumb regarding percentage of 
statements changed). I 

VI. MODEL OF MAINTENANCE 



To explain the dynamic interaction between development and maintenance, as 
exemplified by the changes in metrics values that result from development and 
maintenance actions, the model in Figure 4 is provided- A model of the 
maintenance process is essential for standard! zat i on to be achieved- Different 
organizations may want to use different metrics, depending on the relevance of 
the metrics to their maintenance environments and projects. 



Page 15 



Devel opment 
Methodol ogy 



Contributes 
to Original 
Metrics Values 



A-ffects Ability 
to Make Correct 
Changes 



V New Metrics v 

I Values I 

Compute ?< Recompute! >1 Maintenance 

Common Metrics !< I Actions 



I Changes Metrics 
Val ues 



V 

<Sample List) 
Comp 1 eteness 
Consi stency 
Modul ar i tv 
Traceabi 1 i ty 
Ver 1 liability 



V 

Add 

Del ete 
Modi t y 

Improved I 

Maintainability'^ ! 



V V 



Metrics Data Base 








Maintenance Data 


(Metrics and 


— > 


Correl at i on 


< — 


Base (Maintenance 


Projects History) 




7 




Action History) 



Figure 4. Model of the Interaction between Development, Maintenance and 
Metrics. 
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This model may be understood and applied as -follows: 

A- Evaluate: Estimate the incremental change in metric value at a proposed 
maintenance action- It the sottware change is made, measure its ettect atter 
the change is made. To the extent teasible, quantity the ettect ot the change. 
The tollowing questions are relevant when considering a change to sottware: 

o Given the development methodology and a maintenance action, how will the 
metrics values be attected (magnitude and sign)? Will they change in a 
direction to indicate the sottware will be (or has been) improved? Or will the 
change indicate that the sottware will be (or has been) degraded? 

This model would assist the maintenance organization to: 1> determine 
whether a change should be made, 2) determine whether a change improved 
mai ntai nabi 1 1 t y , it it was made, and 3) document the history ot the project 
and the change so that this intormation can be used when making tuturs change 
deci si ons . 

B. Feedback: Understand that taking a maintenance action changes metrics 
values and that the new metrics values will influence future maintenance 
act i ons . 

C- Data bases: Maintain data bases ot project char ac ter i st i cs , metrics, and 
maintenance actions as an aid to learning trom the past: Was a given metric a 
good predictor ot the ettect ot a given maintenance action? Which maintenance 
actions improved and v^hich degraded the sottware tor given project 
charact er i st 1 cs? Did the nature ot the development methodciogy influence the 
mai nt ai nab i 1 i ty ot the software'^ 

VII. APPLICATION OF METRICS 

It was mentioned previously that metrics are part ot the maintenance model 
— they assist in evaluating the effects ot change- When used over hundreds ot 
sottware components (an element ot a sottware system, like a module), the 
metrics can assume numerical values Ce.a. , tor Compl eteness : ratio ot 
completed components to total number of components in the svstem). For a 
single component, as in the example, a qualitative i n t er pret at i on is 
appropriate. This is done below tor the example, using typical metrics. 
Although the modification has improved functionality, it has degraded 
mai ntai nabi 1 i ty . 
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TABLE 1 



METRICS APPLIED TO EXAMPLE PROGRAM 



Metri c 



Compl e ten ess: 

Are all required 
software components 
present? 

Consistency: 

Are the code and 
documentation 
uniform and free 
of contradi ct i on? 

Modul ari ty : 

Is the structure 
cohesive and self- 
cant ai ned'^ 

Tr aceab 1 1 1 ty : 

Can the program 
parts be traced 
from one to 

another'^ 

Ver i f i abi 1 i ty : 

Can the correct 
operation and 
performance of 
the program be 
ver i f i ed? 



Ori ginal 
Progr am 



Yes 



Yes 



No 



Yes 



Modified Program 



No. The correct comment is missing. 



No. The comment contradicts the 
commands and vice versa. 



No. Quirks of the DOS 1 anguage 
inhibit modularity, but similar 
commands are grouped. 



No. Can't trace between commands, 
drives and directories. 



Yes 



No. The erroneous comment confuses 
the verification. 
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VIII. STANDARDIZATION OF CHANGE DOCUMENTATION 

Because there is a great difference in applications, progr a^^fni ng 
environments, etc., in various organi zat i ons , the maintenance standard snould 
accommodate those differences and specify only a minimum set of requirements 
and procedures. 

Standardization can be viewed as a process of posing questions prior to a 
maintenance action and having the maintainer answer them. The purpose of this 
is to ensure that the maintainer has thought about the consequences of 
proposed changes and is alerted to potential pitfalls. Maintenance decisions 
and actions should be recorded in a data base for use in making future 
maintenance decisions. 

The entities which are subject to change are software components. For the 
sake of brevity, 'software component' will hereafter be called 'component'. 

A. Documenting the Effects of Change 

It should be a standard procedure of maintenance to document a proposed 
change in the following format (or similar format) and, if the change is made, 
to fill in as much detail as possible about the change. The items to be 
considered in deciding on a change are more important than the specific format 
used to document the change. The Xs in the matrix indicate a relationship 
between an input item and an output item, and ' DNA ' means 'DOES NOT APPLY'. 

Change an input (add or modify) 



Type: ! Batch file statements \ 

Format I PC DOS batch file conventions 1 

Value (How are outliers handled? Are they used or rejected?) I DNA I 
Range (e-g., extremes of numbers): ! DNA I 

Precision (e.g., number of decimal points): J DNA ! 

Accuracy (e-g., number within X 7. of actual value): i DNA I 

Name (Standardize name; should say what component does): I (Start) 

Starts User Computer on network and requests resources ! 

Quest i ons : 

* What is the effect of input on outputs? 

1 Link between Start- Bat on User Computer and Server application 
batch files 1 

* What is the effect of input on computation of function? 

* Computation within bounds? (i.e., does input cause computation 
to be outside feasible range of numbers in application?):! DNA ) 
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TABLE 2 

EXAMPLE INPUT-OUTPUT CHANGE RELATIONSHIP 
OUTPUT (Name) 


Type 


Format Value Range Precision Accuracy 


INPUT 

(Name) 





Type X 



Format 


X 


Val ue 


XXX X 


Range 


XXX X 


Preci si on 


XXX X 


Accuracy 


X X X X 



Type; New statements in Start-Bat on User Computer creates need -for new 
statements in application batch tiles. I 

Format: It syntax incorrect, won't work. It output not correctiv rel ated 
to input, could make wrong decision about executing application 
program. I 

Add/Modity a tunction or statements: What resources, tunctions or 

statements must be present so that change can be utilised? 
(Need, tor example, paths, directories, and disks detined) I 
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B. DocLsmentati on Requirements 

As a minimum the -following should be standard document at i on ^or supporting 
maintenance: requirements spec i -f i cat i on , design speci f i cat i on , program 

listing, test plan, and test results, as summarized below. 

Phase Documentati on 



Requirements Analysis Requirements Bpeci -f i cat i on 

I Need environment variables 
to improve useability o-f 
LAN and to simpli-fy 
maintenance- ! 

Design Speci -f i cat i on 

’i State Diagram I 

Li st i ng 

I Batch File J 

Test Plan, Test Results 

I Test use o-f application 
batch -files from all User 
Computers- A1 1 ow access if 
conf i gurat i on permits it: 
otherwise, disallow it. ! 

IX. SOFTWARE COMMON I CAT I ON MECHANISMS AND MAINTENANCE 

Mechanisms which are available for communicating between components are an 
important aspect of maintenance because of the serious consequences of making 
an error in adding or changing a linkage. As opposed to other types of 
software changes, a change in a communication mechanism affects more than one 
component. This is particularly important for networks where a defective 
mechanism can adversely affect the operation of computers at remote sites. 

A- Kinds of Communi cat i on Mechanisms 

o Data linkages (for the transfer of data) : 

- Message passing (can also be control message): I DNA I 

- Transaction (e.g., update in a data base management system): DNA 

- Mail Box (i-e-, store data in standard location where it can be used 

by other processes) 

5 Autoexec- Bat on User Computer stores data (its ID) in standard 
location (environment) that can be used by Profile. Bat on 
Server ! 



Dss i qn 



Coding 



A1 1 
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o Control linkages 

- Subroutine call: 

- Procedure call: 

- Remote procedure 



<-for the transfer of 
; DNA ; 

I DNA I 

call (RPC): ! DNA I 



control ) 



B- Character i st ics of Communication Between Software Components 

1) Expl i ci t : There is an actual transfer or exchange of data or 

passing of parameters, or an output from one component 

is the input to another component, or one component calls 

another component. 

\ Start- Bat on User Computer calls Profile.Bat on Server 

2) I mpl i ci t : Based on the position of the given component within a 

sequence of components (e.g., instructions in a progra.o> 

! Since PROFILE is needed to determine the User Computer 
conf 1 gurat 1 on , it is called as the I ast step <'‘7/ in 
F 1 gur e 2 . 1 

3) I ndi r ec 1 5 Based on one component providing •' e =. q . , store data ^n 

or secondary storage) that another component uses: 

I r r of i i e . Bat on Server sets conf i qur a t i on envi reamer t . 
<^ppiication batch files will ^^e'^erence t^e envi'^onment ' 

Before sompenents ?re added, deleted modif?ed= it shoul n be stanc 
orocedu'^e to ascertain anc docuiTient the ef "^ects of •riakinq the je on in 

component c ommi-.n i ca 1 1 on , Fur t her mor e if the cha-"qe fS made, as “u.ch detail as 
possible should oe documented about the charge, as suggested bv t^ie questions 
bel cw - 



4> ADD a component 



o What other components will the giver component communicate v/ith 
once it added? J component ” batch file statement ! 

! Start . Bat on User Computer will communicate with Profile- Bat 
on Serve"". The environment will communicate with application 
batch files on Server I 

o Chat are the communi cat i on linkages? (parameter passing, message 
exchange, RPC, etc.?) 

1 Start.Bat on User Computer names an executable batch file (e.g.. 
Profile) and causes the file to be loaded and executed. 
Autoexec. Bat sets the User Computer i dent i f i cat i on . Profile- Bat 
on Server sets the conf i gurat i on . I 

o What existing commun i cat i on linkages will be affected by the 
change?: I None I 



1+ U' 
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5) DELETE a component 1 DNA I 

o What communication linkage will be broken by the deletion? 

o What are the new communication linkages that result Trom the 
del et i on? 

6) MODIFY a component 

I Modify Start.Bat and application batch files. These are the 
components to be modified- I 

o What is the existing communication linkage which involves this 
component? 

! None between Start-Bat and application batch files I 

o How will this communication linkage be modified by the change in 
the component? 

{ A communication linkage will be established between User 
Computer and Server via the environment I 

X. STANDARDIZATION THROUGH EXAMINATION OF DEVELOPMENT METHODOLOGIES 

There is evidence that the character i st i cs of development methodologies 
and the character i st i cs of programming 1 anguages v9> can influence 

mai ntai nabi 1 i tv. 

A. Character i st 1 cs of Development Methodology 

When we maintain software we may not be cognizant of the development 
methodology which was used to produce the software, but it will affect our 
ability to maintain the software. The evaluation hinges on a single criterion: 
does the methodology support the creation o-f software which is easy to change 
without inducing side— effects (an unexpected and undesirable result of making 
a change)? This objective will be achieved if the methodology forces the 
designer to formally consider the consequences of making a change once the 
software has to be maintained It follows that in order to capitalize on 

a methodology that supports maintenance, it is necessary to use that 
methodology to maintain the software. The following is a standard procedure 
for evaluating a methodology with respect to its capability to support 
mai ntenance . 
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Does the methodology (e.g., state diagram) assist to: 

1) Identi-f^y si de-e-f ec t s when performing maintenance 

The state diagram (see Figure 3) can assist in 

identifying potential side-effects because it shows: changes 

of state dn a program, events that cause changes in state, and 
resultar^ actions. For example, in Figure 3 the modified state 
diagram jrhpws a transition from the Resources Assigned state 
<st^p the /"Dr i ve E Accessed ' state *(step 6') that could 

have an Effect on loading the directory program (step 7) 
because %he modification has intervened in the original 
program execution sequence. We could have a problem if this 
intervention prevents the directory program from eventually 
being loaded. I 

2) Provide ability to make selective change (i-e., don't change or 
destrov' another part of the software when making a change) 

I Obviously, no methodology is foolproof in identifying the 
consequences of making a change, but a methodologv' like the 
state diagram forces the maintainer to consider the effects of 
change and makes visible the relationship between programs. 
For example, it says in Figure 3 that a program called 
'PROFILE' is to be loaded. This raises some interesting 
questions for the maintainer: What is the program 'PROFILE? 
What does it do? Where is it located? The incorrect 

modification does not answer these questions. The 
correct modification does. However , notice that the state 
diagram does not suggest to the maintainer that the 

comments are incorrect; only the listing can do that. This 
suggests the impossibility of higher level documentation 
providing a complete description of program logic. I 

3) Make visible the dependencies between inputs, processes and 
outputs (dependencies make it difficult to change the software 
without affecting something else which was working correctly 
prior to the change) 

I Dependencies are created by the change between Start-Bat and 
application batch files and between Start.Bat and PROFILE. 
These are unavoidable, given the approach for checking User 
Computer conf i gurat i on - However, the state diagram helps to 
make these dependencies visible- They would be more visible 
to the reader if the state diagram for the processing of the 
PROFILE program were shown (not shown because it is beyond the 
scope of this report). I 

4) Determine whether change can be made without creating an 
incompatibi 1 i ty with the rest of the software 

i This would be determined by analyzing the application batch 
files and state diagrams to see whether an incompatibility 
in their operation would be created by checking the User 
Computer conf i gurat i on - I 
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5) Support a rational change policy: 

0 Make a change, it warranted, and only if it can be done in a 
standard way, a 'standard way' being defined as being in 
conformance with the above procedure for assessing the impact 
of change- 

1 To assess the effect of the change, we determine how the 
changed Start-Bat will affect the application batch files. 

There are three possibilities: 

- They will no longer work at all 

- They will deny program access when the required equipment 
is available 

- They will allow program access when the required equipment 
is not available 

- They will work sat i sf actor i 1 v ! 

D Make changes in small, controlled increments 

! By breaking the logic into discrete state transitions (e-g., 
transition from 'RESOURCES ASSIGNED' (Step 5) to DRIVE E 
ACCESSED (Step 6) in Figure 3), changes are kept smal 1 - 
Also the individual changes are kept small by distributing 
parts of the total change to several batch files (e.g. , 

Start. Bat, Profile-Bat and application batch files>- However, 
the incorrect modification in Figure 2 is uncontrolled, 
raising questions about the function and location of PROFILE 
and its relationship to Start. Bat- { 

B. Characteristics of Programming Language 

Character i st i cs of the programming language can also significantly 
influence the ability to maintain <9}- Two brief examples from the DOS 
language will be given: 

o PATH command: If this command appears once and is repeated, the most recent 

occurrence of the command is the only one in effect. This means that any paths 
used to establish directories in a previous occurrence are lost unless they 
are repeated in the new PATH command. In effect, this means that a new path 
must be a superset of the previous path, if all original directory information 
is to be retained- However, this could result in long path commands and, 
without writing complicated logic, commands are limited to a single line! Thus 
the maintenance principle of being able to make a selective change (i-e., one 
wants to just add or delete parts of the PATH command, not write a new one) 
cannot be achieved with this command. 
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a IF command: The IF command has the tormat: IF stri ng 1 ==stri ng2 command. The 

requirement tor the second ' = ' is une>ipected- This nuance of the language has 
caused us to make several errors in writing network batch files. This 
seemingly minor item can cause havoc in maintenance because a frequent change 
to batch files occurs as the result of adding capabilities to the network that 
are conditioned on the availability of certain resources. The IF command is 
key to specifying these conditions. 

XI. SUMMARY 

We have proposed that maintenance can be improved through standardi zat i on . 
The elements of the proposed standardization process are the following: 

o Metrics 

o Model of maintenance 
o Change documentation 
o Software communication mechanisms 

o Development methodology supportive of maintenance 

An example was presented of the application of one development methodology 
— state diagrams — to illustrate how proposed and accomplished changes can 
be illuminated so that errors can be avoided and maintainability improved. 

Various methodologies could have been used to illustrate the change 
management methodology. What is important is not the particular development 
methodology, but the consistent application of a selected methodoloqv, using 
the change management methodology which has been described. Additional 
research is needed to test other types of applications, programming languages 
and changes against the change management methodology. 
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